home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1639.txt < prev    next >
Text File  |  1994-08-01  |  10KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      D. Piscitello
  8. Request for Comments: 1639                         Core Competence, Inc.
  9. Obsoletes: 1545                                                June 1994
  10. Category: Experimental
  11.  
  12.  
  13.             FTP Operation Over Big Address Records (FOOBAR)
  14.  
  15. Status of this Memo
  16.  
  17.    This memo defines an Experimental Protocol for the Internet
  18.    community.  This memo does not specify an Internet standard of any
  19.    kind.  Discussion and suggestions for improvement are requested.
  20.    Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This paper describes a convention for specifying address families
  25.    other than the default Internet address family in FTP commands and
  26.    replies.
  27.  
  28. Introduction
  29.  
  30.    In the File Transfer Protocol (STD 9, RFC 959), the PORT command
  31.    argument <host-port> specifies the data port to be used to establish
  32.    a data connection for FTP (STD 9, RFC 959).  This argument is also
  33.    used in the PASV reply to request the server-DTP to listen on a data
  34.    port other than its default data port.  This RFC specifies a method
  35.    for assigning addresses other than 32-bit IPv4 addresses to data
  36.    ports through the specification of a "long Port (LPRT)" command and
  37.    "Long Passive (LPSV)" reply, each having as its argument a <long-
  38.    host-port>, which allows for additional address families, variable
  39.    length network addresses and variable length port numbers.
  40.  
  41.    This is a general solution, applicable for all "next generation" IP
  42.    alternatives, as well as for other network protocols than IP.  This
  43.    revision also extends FTP to allow for its operation over transport
  44.    interfaces other than TCP.
  45.  
  46. Acknowledgments
  47.  
  48.    Many thanks to all the folks in the IETF who casually mentioned how
  49.    to do this, but who left it to me to write this RFC.  Special thanks
  50.    to Rich Colella, Bob Ullmann, Steve Lunt, Jay Israel, Jon Postel,
  51.    Shawn Ostermann, and Tae Kyong Song, who contributed to this work.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Piscitello                                                      [Page 1]
  59.  
  60. RFC 1639                  FTP Over Big Address                 June 1994
  61.  
  62.  
  63. 1.  Background
  64.  
  65.    The PORT command of File Transfer Protocol allows users to specify an
  66.    address other than the default data port for the transport connection
  67.    over which data are transferred. The PORT command syntax is:
  68.  
  69.       PORT <SP> <host-port> <CRLF>
  70.  
  71.    The <host-port> argument is the concatenation of a 32-bit internet
  72.    <host-address> and a 16-bit TCP <port-address>. This address
  73.    information is broken into 8-bit fields and the value of each field
  74.    is transmitted as a decimal number (in character string
  75.    representation).  The fields are separated by commas.  A PORT command
  76.    is thus of the general form "PORT h1,h2,h3,h4,p1,p2", where h1 is the
  77.    high order 8 bits of the internet host address.
  78.  
  79.    The <host-port> argument is also used by the PASV reply, and in
  80.    certain negative completion replies.
  81.  
  82.    To accommodate larger network addresses anticipated for all IP "next
  83.    generation" alternatives, and to accommodate FTP operation over
  84.    network and transport protocols other than IP, new commands and reply
  85.    codes are needed for FTP.
  86.  
  87. 2.  The LPRT Command
  88.  
  89.    The LPRT command allows users to specify a "long" address for the
  90.    transport connection over which data are transferred. The LPRT
  91.    command syntax is:
  92.  
  93.       LPRT <SP> <long-host-port> <CRLF>
  94.  
  95.    The <long-host-port> argument is the concatenation of the following
  96.    fields;
  97.  
  98.    o  an 8-bit <address-family> argument (af)
  99.  
  100.    o  an 8-bit <host-address-length> argument (hal)
  101.  
  102.    o  a <host-address> of <host-address-length> (h1, h2, ...)
  103.  
  104.    o  an 8-bit <port-address-length> (pal)
  105.  
  106.    o  a <port-address> of <port-address-length> (p1, p2, ...)
  107.  
  108.    The initial values assigned to the <address-family> argument take the
  109.    value of the version number of IP (see Assigned Numbers, STD 2, RFC
  110.    1340); values in the range of 0-15 decimal are thus reserved for IP
  111.  
  112.  
  113.  
  114. Piscitello                                                      [Page 2]
  115.  
  116. RFC 1639                  FTP Over Big Address                 June 1994
  117.  
  118.  
  119.    and assigned by IANA.  Values in the range 16-255 are available for
  120.    the IANA to assign to all other network layer protocols over which
  121.    FTP may be operated.
  122.  
  123.    Relevant assigned <address-family> numbers for FOOBAR are:
  124.  
  125.      Decimal         Keyword
  126.      ------          -------
  127.      0               reserved
  128.      1-3             unassigned
  129.      4               Internet Protocol (IP)
  130.      5               ST Datagram Mode
  131.      6               SIP
  132.      7               TP/IX
  133.      8               PIP
  134.      9               TUBA
  135.      10-14           unassigned
  136.      15              reserved
  137.      16              Novell IPX
  138.  
  139.    The value of each field is broken into 8-bit fields and the value of
  140.    each field is transmitted as an unsigned decimal number (in character
  141.    string representation, note that negative numbers are explicitly not
  142.    permitted). The fields are separated by commas.
  143.  
  144.    A LPRT command is thus of the general form
  145.  
  146.       LPRT af,hal,h1,h2,h3,h4...,pal,p1,p2...
  147.  
  148.    where h1 is the high order 8 bits of the internet host address, and
  149.    p1 is the high order 8 bits of the port number (transport address).
  150.  
  151. 3.  The LPSV Command
  152.  
  153.    The L(ONG) PASSIVE command requests the server-DTP to listen on a
  154.    data port other than its default data port and to wait for a
  155.    connection rather than initiate one upon receipt of a transfer
  156.    command. The response to this command includes the address family,
  157.    host address length indicator, host address, port address length, and
  158.    port address of the listener process at the server. The reply code
  159.    and text for entering the passive mode using a long address is 228
  160.    (Interpretation according to FTP is: positive completion reply 2yz,
  161.    connections x2z, passive mode entered using long address xy8).
  162.  
  163.    The suggested text message to accompany this reply code is:
  164.  
  165.     228 Entering Long Passive Mode
  166.         (af, hal, h1, h2, h3,..., pal, p1, p2...)
  167.  
  168.  
  169.  
  170. Piscitello                                                      [Page 3]
  171.  
  172. RFC 1639                  FTP Over Big Address                 June 1994
  173.  
  174.  
  175. 4.  Permanent Negative Completion Reply Codes
  176.  
  177.    The negative completion reply codes that are associated with syntax
  178.    errors in the PORT and PASV commands are appropriate for the LPRT and
  179.    LPSV commands (500, 501). An additional negative completion reply
  180.    code is needed to distinguish the case where a host supports the LPRT
  181.    or LPSV command, but does not support the address family specified.
  182.  
  183.    Of the FTP function groupings defined for reply codes (syntax,
  184.    information, connections, authentication and accounting, and file
  185.    system), "connections" seems the most logical choice; thus, an
  186.    additional negative command completion reply code, 521 is added, with
  187.    the following suggested textual message:
  188.  
  189.       521 Supported address families are (af1, af2, ..., afn)
  190.  
  191.    Where (af1, af2, ..., afn) are the values of the version numbers of
  192.    the "next generation" or other protocol families supported. (Note: it
  193.    has been suggested that the families could also be represented by
  194.    ASCII strings.)
  195.  
  196. 5.  Rationale
  197.  
  198.    An explicit address family argument in the LPRT command and LPSV
  199.    reply allows the Internet community to experiment with a variety of
  200.    "next generation IP" and other network layer protocol alternatives
  201.    within a common FTP implementation framework. (It also allows the use
  202.    of a different address family on the command and data connections.)
  203.    An explicit length indicator for the host address is necessary
  204.    because some of the IPNG alternatives make use of variable length
  205.    addresses. An explicit host address is necessary because FTP says
  206.    it's necessary.
  207.  
  208.    The decision to provide a length indicator for the port number is not
  209.    as obvious, and certainly goes beyond the necessary condition of
  210.    having to support TCP port numbers.
  211.  
  212.    Currently, at least one IPng alternative (TP/IX) supports longer port
  213.    addresses. And given the increasingly "multi-protocol" nature of the
  214.    Internet, it seems reasonable that someone, somewhere, might wish to
  215.    operate FTP operate over Appletalk, IPX, and OSI networks as well as
  216.    TCP/IP networks.  (In theory, FTP should operate over *any* transport
  217.    protocol that offers the same service as TCP.)  Since some of these
  218.    transport protocols may offer transport selectors or port numbers
  219.    that exceed 16 bits, a length indicator may be desirable. If FTP must
  220.    indeed be changed to accommodate larger network addresses, it may be
  221.    prudent to determine at this time whether the same flexibility is
  222.    useful or necessary with respect to transport addresses.
  223.  
  224.  
  225.  
  226. Piscitello                                                      [Page 4]
  227.  
  228. RFC 1639                  FTP Over Big Address                 June 1994
  229.  
  230.  
  231. 6.  Conclusions
  232.  
  233.    The mechanism defined here is simple, extensible, and meets both IPNG
  234.    and multi-protocol internet needs.
  235.  
  236. 7.  References
  237.  
  238.    STD 9, RFC 959  Postel, J., and J. Reynolds, "File Transfer Protocol",
  239.                    STD 9, RFC 959, USC/Information Sciences Institute,
  240.                    October 1985.
  241.  
  242.    STD 2, RFC 1340 Reynolds, J., and J. Postel, "Assigned Numbers",
  243.                    STD 2, RFC 1340, USC/Information Sciences Institute,
  244.                    July 1992.  (Does not include recently assigned IPv7
  245.                    numbers).
  246.  
  247.    STD 3, RFC 1123 Braden, R., Editor, "Requirements for Internet
  248.                    Hosts - Application and Support", STD 3, RFC 1123,
  249.                    USC/Information Sciences Institute, October 1989.
  250.  
  251. 8.  Security Considerations
  252.  
  253.    Security issues are not discussed in this memo.
  254.  
  255. 9.  Author's Address
  256.  
  257.    David M. Piscitello
  258.    Core Competence, Inc.
  259.    1620 Tuckerstown Road
  260.    Dresher, PA 19025
  261.  
  262.    EMail: dave@corecom.com
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Piscitello                                                      [Page 5]
  283.  
  284.